All Categories :
Servers
Chapter 10
Intranet Security in Windows NT
CONTENTS
You might think that there is little reason to be concerned about
security in an Intranet. After all, by definition an Intranet
is internal to your organization; outsiders can't access it. Also,
because one of your objectives in setting up your Intranet is
to provide your customers with access to a wide variety of public
documents, there might seem little need to secure access to them.
These are strong arguments for the position that an Intranet should
be completely open to its customers, with little or no security.
You may not have considered your Intranet in any other light.
On the other hand, implementing some simple, built-in security
measures in your Intranet can allow you to provide resources you
may not have considered possible in such a context. For example,
you can give access to certain Web pages to some people without
making them available to your entire customer base by using one
of several kinds of authentication. In this chapter, you learn
how to use simple security measures to widen the scope of your
Intranet.
Intranet security is a multifaceted issue with both opportunities
and dangers, especially if your network is part of the Internet.
This chapter walks through the major issues and provides detailed
information on using built-in Intranet security features.
Warning |
Except in the sections of this chapter that are specifically devoted to Internet security issues, it's assumed your Intranet is not accessible from outside your organization. If you are on the Internet, the Intranet security measures discussed in this chapter may not be sufficient to secure your system. If you want to make the services and resources of your Intranet accessible from the outside, you'll need to take significant additional steps to prevent abuse and/or unauthorized access. Some of these steps are described at the end of this chapter in the section "Your Intranet and the Internet" and in Chapter 28, "Connecting the Intranet and the Internet."
|
Many people view computer and network security in a negative light,
thinking of it only in terms of restricting access to services.
One major view of network security is "that which is not
expressly permitted, is denied." Although this view is a
good way of thinking about how to connect your organization to
the Internet, you can, and possibly should, view Intranet security
from a more positive angle. Properly set up, Intranet security
can be an enabler, enriching your Intranet with services and resources
you would not be able to otherwise provide. Such an overall security
policy might be described as "that which is not expressly
denied, is permitted."
This chapter takes the latter approach, presenting Intranet security
in terms of its opportunities for adding value to your Intranet.
For example, some of your customers may have information they'd
like to make available, confidential management or financial information,
for example, provided that access to it can be limited to a specified
group. Without the ability to ensure that only those who have
the right to see such information will have access, the custodians
of such data will not be willing to put it on an Intranet. Providing
security increases your organization's ability to use the important
collaborative aspects of an Intranet.
The more defensive approach, preventing abuse of your Intranet,
should also be considered. Organizations' needs for security in
an Intranet can vary widely. Businesses in which confidentiality
and discretion is the norm in handling proprietary information
and corporate intellectual property have different needs than
a college or university, for example. Academic institutions generally
tilt toward making the free exchange of ideas a primary interest.
At the same time, though, the curiosity (to use a polite word)
of undergraduates imposes strong needs for security. Keeping prying
sophomores out of university administration computing resources
is a high priority. For example, students have been known to try
to access grade records (their own or those of others) for various
reasons. Adolescent pranks take on new dimensions on a computer
network.
What Are the Security Features of an Intranet?
Before learning about how you can use security to enhance your
Intranet, you should know what security features are available
to you. These features break down into three main categories.
First, you can take steps in your Web server software to set up
security. Second, you can take steps with the other TCP/IP network
services you've set up on your Intranet to enhance their security.
Third, you can secure Windows NT Server as a network operating
system irrespective of the fact that it is being used as a Web
server. I address each of these categories throughout this chapter.
Another feature worthy of brief mention is that some Mosaic browsers
allow you to secure the browser to limit what the customers can
do with them. But this feature, referred to as kiosk mode,
is not widely available.
Security in Your Other Intranet Applications
Although the main focus of this chapter is Web security, you can
and should implement security and access controls in some of the
other network services that you learned about in Chapters 8
and 9. The following are some of the steps
you can take:
- You can limit access to your anonymous
FTP server in several important ways, much like with your HTTP
server, while still enabling authorized customers to upload files
to it.
- If you choose to run a Usenet news server,
you can limit access in much the same way as FTP and HTTP.
- You can control access to searchable Intranet
indices and databases (see Chapter 21,
"Indexing Your Intranet with WAIS") through password-protected
Web interfaces.
- You can control access to Gopher services
based on TCP/IP network address and set separate read and search
permissions on a per-directory basis.
This chapter doesn't provide any additional information about
these services. Refer to the documentation for these network packages
and to the help files with the NT User Manager application to
learn about how to handle access control and other security features
in these other network services.
It's Your Call
It's your responsibility to determine the level of security you
need on your Intranet and, of course, to implement it. Putting
most of the security measures mentioned into place, as you'll
learn in the following sections, is not difficult. Your primary
concern will be explaining to customers how Intranet security
works not so much as a limiting factor, but as an opportunity
for increased use and collaboration using your Intranet. Assuring
decision-makers that they can post information on your Intranet
in a secure fashion can go a long way toward making your Intranet
a success. At the same time, it's important to make sure both
information providers and their customers understand a number
of critical aspects of Intranet security, so they don't inadvertently
defeat the purpose of it.
There are network security commonplaces, unrelated to Intranet
security specifically, that need your attention. All the security
precautions in the world can't protect your Intranet from overall
poor security practices. Poor user choices on passwords always
leads the list of computer and network security risks. If Bob
uses his own name as his password, or his significant other's
or pet's name, password-guessing is simple for anyone who knows
him. Some people even write their passwords down and tape them
to their keyboards or monitors-so much for the security of those
passwords. You can limit access to a sensitive Web resource based
on the TCP/IP network address of the boss's PC, but if the boss
walks away and leaves his PC unattended without a password screen
lock (a feature in many screen savers), anyone who walks into
the empty office can access the protected resources.
In other words, the same good security practices that should be
followed in any networked computing environment should also be
made to apply in your Intranet. Not doing so negates all the possible
security steps you can take and reduces the value of your Intranet.
Even in the absence of malice, the failure to maintain any security
on your Intranet inevitably results in an Intranet with little
value to its customers.
The following list summarizes the wide range of very flexible
security features you can implement on your Web server:
- You can set your server to require a user
name and password for access to Web servers, individual Web pages,
and entire directories containing Web pages.
- You can limit access to Web servers, individual
Web pages, and entire directories containing Web pages to customers
on specific computer systems. In other words, access is denied
unless the user is at his or her usual computer or workstation.
- You can organize individuals and/or computers
into groups and grant access to individual Web servers, Web pages,
and entire directories containing Web pages based on group membership.
- CGI scripts on your Web server can use
any of the preceding access restrictions, though you must take
care in writing them to ensure you don't make security-related
mistakes.
- Some HTTP server software is capable of
communicating with compatible Web browsers in a verifiably secure,
encrypted fashion, defeating even network-level sniffers and ensuring
confidential data transmission across your Intranet.
You can combine these features in a number of ways, such as requiring
a password and limiting access to a group of users who must access
your Web server from a specific group of computer systems. Combining
two, or even all three, of these methods provides the best overall
security.
User Name/Password Authentication
The first major element of Web server security is user name/password
authentication. As you saw in Chapter 7,
the IIS Web server provides this basic kind of security. Figure
10.1 shows what the Web browser user sees when he encounters a
Web page that requires user name/password authentication for access.
Figure 10.1: The user is prompted to enter a user name and password to gain access to a protected Web page.
In IIS, a Web page or an entire directory tree under the Web server
document root can be protected with just three easy steps:
- Using Explorer, right-click the file or directory you want
to protect. On a FAT-formatted drive, choose Properties | Permissions
(the drive or directory must have sharing enabled). On an NTFS-formatted
drive, choose Properties | Security | Permissions. Grant Read
permission for the user or group that you want to be allowed to
view the Web pages, as shown in Figure 10.2. (This step assumes
that you have previously entered the users and/or groups into
User Manager for Domains.)
Figure 10.2: Granting user/group permissions to a directory in Explorer.
- While you're in the Directory Permissions dialog in Explorer,
remove the Read permission for the IUSR_computername
account on the given file or directory. The IUSR_computername
account is used by IIS for anonymous access.
- Run the Microsoft Internet Service Manager and view the properties
for the WWW Service. Notice three options for Password Authentication
in the Service tab: Allow Anonymous, Basic (Clear Text), and Windows
NT Challenge/Response. (See Figure 10.3.) For now, ensure that
all three options are checked. (See following paragraph for more
explanation.)
Figure 10.3: Enabling Password Authentication in the IIS Web server.
Now customers who want to access that directory will be faced
with a dialog in their browser similar to Figure 10.1. But why
did I suggest that you use all three IIS methods for password
authentication? First, you probably want to keep the option for
Allow Anonymous checked for the benefit of all your customers
who want to access your Intranet home page. Unless, of course,
you want to protect your whole Intranet!
Second, the Basic (Clear Text) option is enabled because that
is all the page retrieval security that most Web browsers currently
support. The Challenge/Response option is a much tighter security
method provided by IIS on NT networks, but it is only compatible
with Internet Explorer.
If any customers on your Intranet do have Internet Explorer, those
passwords will be passed between the browser and the server in
a more secure fashion if the third option is enabled. For those
customers who don't have Internet Explorer, option two will provide
a basic encoding (called uuencode) that is very simple
to decipher if anyone should stick a packet sniffer on your LAN.
Note |
Don't confuse page retrieval security with secure transactions on the Web. The former is used to regulate whether a particular Web page is viewable by a particular customer. The latter is used to encrypt the form data that is sent back to the server by the browser after the user is done filling out a Web page that has been viewed. The Secure Sockets Layer (SSL) technology, now supported by many browsers, is an example of the latter.
|
Suppose your HTTP server's document root directory contains three
main subdirectories named public,
management, and personnel.
Using NT directory permissions, you can specify that access to
the management and personnel
subdirectory trees requires user name/password authentication
and leave public open for
anyone to access without being prompted for user name and password.
You can also set up more specific permissions within the protected
subdirectories to further limit access to particularly sensitive
documents by using user names and passwords.
Important Warnings About User Name/Password Authentication
Unless the access rules change as a user moves around on your
Intranet Web pages (as with the personnel/management
subdirectory in the example above), he will be prompted only once
in his browser session for a user name and password. As long as
he continues his browser session, he can access all of the files
and directories available to him under the most recent access
rule without being prompted again for his password. This situation
is for convenience's sake; customers shouldn't have to repeatedly
provide their user names and passwords at each step of the way
when the access rule hasn't changed.
However, this situation has important ramifications if you follow
it out logically. Suppose Anne, having authenticated herself to
access the management subdirectory,
leaves her browser session running, as most of us do. Her privileged
access remains open to all the files protected by that one-time,
possibly days-old, authentication. If she leaves her computer
unattended when she goes to lunch or goes home for the day, without
any sort of active screen or office door lock, anyone can sit
down and browse the files and directories that are supposed to
be limited to Anne's eyes only. This potential security breach
is one that you as Webmaster can do little about and it is one
that can be potentially harmful to all your work. This situation
is no different from when a user leaves his workstation unattended
without logging off. The most you can do is to try to educate
your customers about such everyday security matters, even though
they have little to do directly with the subject of your Intranet.
Authentication Based on Network Hostname or Address
Nearly all Web servers, including IIS, provide an additional authentication
method that uses the TCP/IP network address of customer workstations
or PCs as access criteria. As you'll learn in later chapters in
the context of CGI-bin programming, every Web browser request
for a document or other Intranet resource contains the numerical
IP address of the requesting computer.
An important point about IP address authentication is that the
Web server software blindly accepts the word of a requesting computer
when it sends its IP address. There is no verification possible
of this information. A curious, mischievous, or malicious person
can reconfigure his computer to impersonate someone else's by
changing his computer's IP address. Although this is an over-all
network security issue, not specifically one for your Intranet,
you need to know about it because it can affect the security of
your access-controlled documents. Security-minded network administrators
can use special hardware and software to prevent this sort of
IP spoofing, but for your Intranet's purposes, you'll probably
want to combine hostname/IP address authentication with user name/password
authentication.
You can further enhance security on your Intranet by encrypting
Web transactions. When you use an encryption facility, information
submitted by customers using Web fill-in forms, including user
names, passwords, and other confidential information, can be transmitted
securely to and from the Web server.
A wide range of proposed and/or partially implemented encryption
solutions for the Web exist, but most are not ready for prime
time. Of the several proposed methods, only the Secure HTTP (S-HTTP)
and Secure Socket Layer (SSL) protocols have emerged in anything
like full-blown form. Unfortunately, the two are usually implemented
mutually exclusively, though compatibility is possible. Worse,
Web browsers and servers that support one method don't support
the other, so you can reliably use one or the other only if you
carefully match your Web server and customers' browsers.
S-HTTP
Secure HTTP was developed by Enterprise Integration Technologies
and RSA Data Security, and the public S-HTTP standards are now
managed by CommerceNet, a not-for-profit consortium that is conducting
the first large-scale market trial of technologies and business
processes to support electronic commerce over the Internet. (For
general information on CommerceNet, see http://www.commerce.net/.)
S-HTTP is a modified version of the current HTTP protocol. It
supports the following:
- User and Web server authentication using
digital signatures, and signature keys using both the RSA and
MD5 algorithms
- Privacy of transactions, using several
different key-based encryption methods
- Generation of key certificates for server
authentication
As with SSL, you must have a compatible Web server and browser
that both support S-HTTP transactions in order to use this technology.
IIS 1.0 supports only SSL.
SSL
S-HTTP seems to have been engulfed in the 1995 Netscape tidal
wave. Unwilling to wait for widely accepted HTTP security standards
to evolve (as it was with HTML as well), Netscape Communications
Corporation developed its own Secure Sockets Layer encryption
mechanism. SSL occupies a spot on the ISO seven-layer network
reference below that of the HTTP protocol, which operates at the
application layer. (See Table 10.1.) Rather than developing a
completely new protocol to replace HTTP, SSL sits between HTTP
and the underlying TCP/IP network protocols and can intervene
to create secure transactions. Netscape makes the technical details
of SSL publicly available. In addition, C-language source code
for a reference implementation of SSL is freely available for
non-commercial use. Microsoft includes SSL support in both IIS
and Internet Explorer.
Table 10.1 provides a brief description of each of the seven layers
of the OSI model. Note that layer 1 is contained in hardware and
layers 2 through 7 are implemented in software. The list seems
to be in reverse order. Network engineers generally view the flow
of data as originating at the application layer and moving downward
through the layers toward the hardware. Then the process is reversed
when the packet arrives at the destination.
Table 10.1. An overview of the seven layers of the
OSI model.
Layer | Implemented in
| Description |
Layer 7 | Application | The program's users interact with to initiate network data transfer.
|
Layer 6 | Presentation | Encrypts or decrypts data, packs or unpacks data, and converts data between formats.
|
Layer 5 | Session | Determines when data transmission will start and stop.
|
Layer 4 | Transport | Concerned with the quality of data on the circuit; includes error-checking protocols.
|
Layer 3 | Network | Establishes the network route from the sender to the recipient.
|
Layer 2 | Data Link | Provides for the bundling of several bits into a data frame.
|
Layer 1 | Physical | Includes the specifications for the electrical signals and the transmission of bits.
|
Given Netscape's and Microsoft's collective share of the Web browser
market, S-HTTP doesn't seem to have much of a chance of becoming
widely available. With the exception of NCSA Mosaic, most other
Web browsers have-or have promised-SSL support. Some of them are
Spry's Internet in a Box and Mosaic in a Box for Windows 95 and
version 2.0 and 3.0 of Microsoft's Internet Explorer for Windows
95, Windows NT, and the Macintosh. By the time you read this chapter,
all these packages may have completed their SSL implementations.
Note |
Even though a browser may support secure transactions using SSL or S-HTTP, no transactions are actually secure except those between the browser and a compatible Web server. It's also important to note that most mechanisms for passing Web services through network firewalls (proxying, for example) don't support secure transactions unless both the proxy server and the destination server do.
|
The IIS online documentation includes much more detailed information
about how to obtain and configure SSL.
CGI is the mechanism that stands behind all the wonderful, interactive
fill-in forms you'll want to put on your Intranet. Your customers
demand these kinds of Intranet resources, and later chapters of
Building an Intranet with Windows NT 4 provide a number
of technical tips on creating CGI scripts. You need to be aware,
though, that CGI applications open potential security problems.
You can minimize much of your risk for security breaches in CGI
scripting by including in your scripts explicit code for dealing
with unexpected user input. The reason for this is simple: You
should never trust any information a user enters in a fill-in
form. Just because, for instance, a fill-in form asks for a user's
name or e-mail address, there is no guarantee that the user filling
in the form won't put in incorrect information. Customers make
typographical errors, but probing crackers, even those inside
your organization, may intentionally enter unexpected data in
an attempt to break the script. To be secure, your CGI scripts
have to anticipate and deal safely with unexpected input.
Other problems inherent with CGI scripts include the following:
- Calling outside programs, which opens
up potential security holes in the external program
- Using server-side includes in scripts
that dynamically generate HTML code. Make sure user input doesn't
include literal HTML markup that could call a server-side include
when your script runs.
Paul Phillips maintains a short but powerful list of CGI security
resources on the Web. Check out http://www.cerf.net/~paulp/cgi-security,
where you'll find a number of documents spelling out these and
other risks of CGI scripting. For an extensive list of general
CGI-related resources, go to Yahoo's CGI page, at http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/CGI_Common_Gateway_Interface/index.html.
Is your Intranet accessible from the Internet? If so, all the
security problems of the Internet are now your Intranet's problems
too. Throughout this book, an implicit assumption has been made
that your Intranet is private to your organization. You can, however,
connect safely to the Internet and still protect your Intranet.
You can even use the Internet as a means of letting remote sites
in your company access your Intranet. In Chapter 28,
I'll discuss how to set up NT, RAS, and your modem as a simple
router between your LAN and the Internet. The following sections
cover some Internet security basics.
Firewalls
It's a fact of Internet life that there are people out there who
want to break into other people's networks through the Internet.
Reasons vary from innocent curiosity to malicious cracking to
business and international espionage. At the same time, the value
of the Internet to organizations and businesses is so great that
vendors are rushing to fill the need for Internet security with
Internet firewalls. An Internet firewall is a device that sits
between your internal network and the outside Internet. Its purpose
is to limit access into and out of your network based on your
organization's access policy.
A firewall can be anything from a set of filtering rules set up
on the router between you and the Internet to an elaborate application
gateway consisting of one or more specially configured computers
that control access. Firewalls permit desired services coming
from the outside, such as Internet e-mail, to pass. In addition,
most firewalls now allow access to the World Wide Web from inside
the protected networks. The idea is to allow some services to
pass but to deny others. For example, you may be able to use the
Telnet utility to log into systems out on the Internet, but users
on remote systems cannot use it to log into your local system
because of the firewall.
The following are a couple of good general Web resources about
Internet firewalls:
If your company is also connected to the Internet, you need to
know how to make sure your Intranet isn't generally accessible
to the outside world. You learned earlier in this chapter about
denying access to your Web server using hostname and IP address
authentication, but the fact that IP addresses can be easily spoofed
makes it essential that you not rely on this mechanism as your
only protection. You'll still want to rely on an Internet firewall
to protect your Intranet, as well as all your other network assets.
Unless your corporate network is not connected to the outside
world at all, you'll probably want to ensure the security of your
other Intranet services as well, including not only your Web servers,
but also your FTP, Gopher, Usenet news, WAIS, and other TCP/IP
network services.
Virtual Intranet
More and more companies with widely distributed offices, manufacturing
sites, and other facilities are turning to use of the Internet
to replace private corporate networks connecting the sites. Such
a situation involves multiple connections to the Internet by the
company, with the use of the Internet itself as the backbone network
for the company. Although such an approach is fraught with security
risks, many organizations are using it for non-sensitive information
exchange within the company. Using a properly set up firewall,
companies can provide access to services inside one site's network
to users at another site. Still, however, the data that flows
across the Internet backbones between the corporate sites is mostly
unencrypted, plain text data that Internet snoopers can easily
read. Standard firewalls don't help with this situation.
A number of firewall companies have recently developed Virtual
Private Network (VPN) capabilities. Essentially, VPN is an extension
of standard firewall capabilities to permit authenticated, encrypted
communications between sites over the Internet. Using a VPN, users
at a remote site can access sensitive data at another site in
a secure fashion over the Internet. All the data that flows on
the public Internet backbones is encrypted before it leaves the
local network, and then is decrypted when it arrives at the other
end of the connection.
The most mature VPN product comes from Raptor Systems (http://www.raptor.com/)
as part of the company's Eagle family of products.Other products
are available from Checkpoint (http://www.checkpoint.com/)
and Telecommerce (http://www.telecommerce.com/).
Unfortunately, the market for Windows NT firewall products is
still very young; most products are still exclusively based on
UNIX.
When people think about security on the Internet, they automatically
think about firewalls, but there is a lot more to security than
just firewalls. You will keep away most general pranksters by
setting up your site with security in mind. The following are
some miscellaneous pointers for running a secure Web site:
- Disable the NT Guest account in User Manager
and rename the Administrator account (silly_admin, for example).
- Don't let server applications run as system
services. Because server applications are basically listening
to a port, a hacker could pass data to the well-known port. If
the application is running as a system service, the application
has system privileges and could, in theory, be forced to run a
program that you do not want it to run. It is always best to create
an account for the server application to run under so that it
has only the privileges necessary to do its job.
- Don't put any files in the directory of
an application server that you can't afford to lose.
- Don't provide Write permission to the
CGI and ISAPI \Scripts directory to anyone but those trusted with
NT administration.
- Use Control Panel | Networks to unbind
protocols that are not essential to your LAN.
- Either make sure that Directory Browsing
is not enabled in the IIS WWW Service tab, or make sure that you
place a file named default.htm
in your document root directory. Otherwise, users who only key
in your fully qualified domain name will end up with an FTP directory
listing of your document root directory, and there might be files
other than your home page that you don't want them to see.
- Develop a security policy for users whom
you allow to log into your server. What programs are they allowed
to run? How often must they change their password? Are users permitted
to dial out to the Internet from a private modem?
- Monitor your system logs carefully and
often. It might be your only chance to catch strange behavior
as it begins to develop. If you're lucky, you'll be able to exclude
a hacker before further damage is done.
This chapter has dealt with implementing security on your Intranet.
Although an Intranet is, by definition, internal to an organization,
security is important not so much because it prevents things,
but because it enables them. Judicious use of built-in security
features of Web servers and other Intranet resources can add value
to your Intranet by making new things possible. In this chapter,
you have done the following:
- Considered the overall security aspects
of your Intranet
- Learned how implementing security can
broaden the ways in which your Intranet can be useful in your
organization
- Learned how to use user name/password
authentication to limit access to resources on your Intranet
- Learned about encrypted data transmission
on your Intranet to protect critical
information
- Learned important information about securing
access to your Intranet in the case where your corporate network
is attached to the Internet
- Learned how to provide and limit secure
access to your Intranet from outside your immediate local network
Part III turns to the setup and use of everyday office applications
as Intranet tools.

Contact
reference@developer.com with questions or comments.
Copyright 1998
EarthWeb Inc., All rights reserved.
PLEASE READ THE ACCEPTABLE USAGE STATEMENT.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.